Unity_5_Game by 2015

Author:2015
Language: eng
Format: epub

Reducing this value (increasing the frequency) will force the Physics System to process more frequently, giving it a better chance of catching collisions between our Dynamic, Discrete objects. Naturally, this comes with a CPU cost since we’re invoking more FixedUpdate() callbacks, as well as asking the Physics Engine to update more frequently, having it move objects and verify collisions more often. Conversely, increasing this value (decreasing the frequency) provides more time for the CPU to complete other tasks before it must handle physics processing again, or looking at it from another perspective, giving the Physics System more time to process the last timestep before it begins processing the next one. But, lowering the FixedUpdate frequency would essentially lower the maximum velocity at which objects can be moving before the Physics System can no longer capture collisions between discrete objects (depending on the objects’ sizes).

This makes it absolutely vital to perform a significant amount of testing each time the Fixed Timestep value is changed. Even with a complete understanding of how this value works, it is difficult to predict what the overall outcome will look like during gameplay, and whether the result is passable for quality purposes. Hence, changes to this value should be made early in the project’s lifecycle and then made infrequently in order to get a sufficient amount of testing against as many physics situations as possible. It might help to create a test Scene that flings some of our high-velocity objects at one another to see if the results are acceptable, and run through this Scene whenever Fixed Timestep changes are made. But actual gameplay tends to be rather complex, with many background tasks and unanticipated player behavior that causes additional work for the Physics System, or gives it less time to process the current iteration. Actual gameplay conditions are difficult to duplicate in a vacuum, and there’s no substitute for the real thing, so the more testing we can accomplish against the current value of Fixed Timestep , the more confident we can be that the changes meet acceptable quality standards. We always have the continuous collision detection options as a last resort to offset some of the resulting instability we’re observing. But unfortunately, even if the changes are targeted, it is more likely that this will cause further performance issues than we started with due to the overhead costs of continuous collision detection. It would be wise to profile our Scene before and after enabling continuous collision detection to verify that the benefits are outweighing the costs.

Adjust the Maximum Allowed Timestep If the Maximum Allowed Timestep value gets hit regularly, then it will result in some pretty bizarre-looking physics behavior. Rigidbody objects will appear to slow down or freeze in space, since the Physics Engine needs to keep exiting early before it has fully resolved its entire time quota. In this case, it is a clear sign that we need to optimize our physics from other angles. But at the very least we can be confident the threshold will prevent the game from completely locking up during a physics processing spike. This setting can be accessed through Edit | Project Settings | Time | Maximum Allowed Timestep . The default setting is to consume a maximum of 0.333 seconds, which would manifest itself as a very noticeable drop in frame rate (a mere 3 FPS) if it were breached. If we ever feel the need to change this setting, then we obviously have some big problems with our physics workload, so it is recommended to only tweak this value if we have exhausted all other approaches.

Minimize cast and bounding-volume checks All of the raycasting methods are incredibly useful, but they are relatively expensive (particularly CapsuleCast() and SphereCast() ), requiring us to minimize how often they are called. We should avoid calling these methods regularly within Update callbacks or Coroutines, saving them only for key events in our script code. If we absolutely must rely on persistent line, ray, or area-of-effect collision areas in our Scene (examples include security lasers, or continuously burning fires), then they would be better simulated using a simple Trigger Collider, rather than performing continuous raycasting or overlap checks.

If such replacements are not possible, and we truly need persistent casting checks using these methods (such as a red-dot laser sight), then we can minimize the amount of processing each call makes by exploiting the LayerMask objects. For example, a lazy raycast would look like so:

[SerializeField] float _maxRaycastDistance;

void PerformRaycast() {

RaycastHit hitInfo = new RaycastHit();

if (Physics.Raycast(new Ray(transform.position, transform.forward), out hit, _maxRaycastDistance)) {

// handle raycast result here

}

}

But this overload of Physics.Raycast() will cause the ray to collide with the first object of any layer in its path. The Physics.Raycast method has multiple overloads that accept a LayerMask object for an argument. We can use this to customize which objects should be checked by the raycast, simplifying the workload for the Physics Engine: [SerializeField] float _maxRaycastDistance; [SerializeField] LayerMask _layerMask;

void PerformRaycast() {

RaycastHit hitInfo = new RaycastHit();

if (Physics.Raycast(new Ray(transform.position, transform.forward), out hit, _maxRaycastDistance, _layerMask )) { // handle raycast result here

}

}

The LayerMask object can then be configured through the object’s Inspector view:

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.